Cross platform user joining

ABSTRACT

Techniques for cross platform user joining are disclosed. In some embodiments, cross platform user joining includes associating a first user identification (UID) and a second UID with one or more Internet Protocol addresses (IPs); associating the first UID and the second UID with one or more monitored behaviors; and joining the first UID and the second UID based on the one or more IPs and the one or more monitored behaviors.

CROSS REFERENCE TO OTHER APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 14/264,569 entitled CROSS PLATFORM USER JOINING filed Apr. 29,2014, which claims priority to U.S. Provisional Patent Application No.61/822,800 entitled CROSS PLATFORM USER JOINING filed May 13, 2013, bothof which are incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

Internet-based web services can be delivered through web sites on theWorld Wide Web (WWW). A web site is typically a set of related web pagesserved from a web domain. Web pages are often formatted using HyperTextMarkup Language (HTML), eXtensible HTML (XHTML), or using anotherlanguage that can be processed by a web browser that is typicallyexecuted on a user's client device, such as a computer, tablet, phablet,smart phone, smart television, or other client device. A web site isgenerally hosted on a web server. The web server is typically accessiblevia a network, such as the Internet, through a web address, which isgenerally known as a Uniform Resource Indicator (URI) or a UniformResource Locator (URL).

For example, a web service can be delivered via a web site. In somecases, the web site can allow users to access content delivered via theweb site using anonymous user access. Some web sites can allow orrequire that users login to access some or all of the content deliveredvia the web site (e.g., subscription access may be required to accesscertain content on the web site, such as for an online newspaper, ane-commerce shopping site, a social networking web site, a web-basedemail service, a file sharing web site, and/or other web services).

A web site can be a static web site. Generally, a static web site doesnot customize content delivered to different users of the web site(e.g., a static web site has web pages stored on a web server in theformat that is sent to a client web browser).

A web site can be a dynamic web site or can include dynamic web pages.Generally, a dynamic web site can customize content delivered todifferent users of the web site (e.g., a dynamic web site is one thatcan change or customize web content automatically).

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention are disclosed in the followingdetailed description and the accompanying drawings.

FIG. 1 is a block diagram illustrating an overview of an architecture ofa system for providing cross platform user joining in accordance withsome embodiments.

FIG. 2 is a functional block diagram illustrating a cross platform userjoining engine in accordance with some embodiments.

FIG. 3 is a functional diagram illustrating an architecture forIP-based, behavior signal, and other signal processing for providingcross platform user joining in accordance with some embodiments.

FIG. 4 is a graph diagram illustrating an association of IP addressesand UIDs for providing cross platform user joining in accordance withsome embodiments.

FIGS. 5A and 5B are functional block diagrams illustrating overviews ofan offline architecture and an online architecture of a system forproviding cross platform user joining in accordance with someembodiments.

FIG. 6 is a functional diagram illustrating an architecture for IP-basedUID processing for providing cross platform user joining in accordancewith some embodiments.

FIG. 7 is a screen diagram illustrating a graphical user interface (GUI)of a web interface for providing cross platform user joining inaccordance with some embodiments.

FIG. 8 is a flow diagram illustrating a process for providing crossplatform user joining in accordance with some embodiments.

FIG. 9 is another flow diagram illustrating a process for providingcross platform user joining in accordance with some embodiments.

DETAILED DESCRIPTION

The invention can be implemented in numerous ways, including as aprocess; an apparatus; a system; a composition of matter; a computerprogram product embodied on a computer readable storage medium; and/or aprocessor, such as a processor configured to execute instructions storedon and/or provided by a memory coupled to the processor. In thisspecification, these implementations, or any other form that theinvention may take, may be referred to as techniques. In general, theorder of the steps of disclosed processes may be altered within thescope of the invention. Unless stated otherwise, a component such as aprocessor or a memory described as being configured to perform a taskmay be implemented as a general component that is temporarily configuredto perform the task at a given time or a specific component that ismanufactured to perform the task. As used herein, the term ‘processor’refers to one or more devices, circuits, and/or processing coresconfigured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention isprovided below along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such embodiments, but the invention is not limited to anyembodiment. The scope of the invention is limited only by the claims andthe invention encompasses numerous alternatives, modifications andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example and theinvention may be practiced according to the claims without some or allof these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

Existing web sites can generally track activities of users on the website (e.g., monitoring and tracking a user's browsing activity during asession on the web site). For example, the web site can use cookies(e.g., in pixel logs, in which cookies are used to identify a user, atleast anonymously, per device, and in which the cookies are typicallypersistent on the device, that is, the cookies are stored acrosssessions) or other approaches to track a user's activity on the website. Thus, what is being actively browsed, viewed, and/or other useractivities on the web site can be tracked. But if the user isanonymously accessing (e.g., browsing) the web site (e.g., if the userhas not logged into/signed into the web site and/or has not otherwiseverified the user's identity with the web site using a type of userauthorization/authentication, such as username, a username and password,a biometric verification of a user, a token, or other schemes orcombinations thereof), then the web site generally cannot associate suchtracked user activities with a specific/confirmed user identity.

However, as web sites continue to develop new services and content forusers, there is an increasing need to be able to identify users even ifthe user has not logged into the web site and/or has not otherwiseauthenticated or verified the user's identity with the web site.

For example, there is a need for service providers to control the mannerof presentation and/or to customize the content and/or services that arepresented for each user. Customization and personalization with respectto interface, content, and other aspects can lead to additional revenuefor the service provider and can also provide a better user experiencefor its users. Thus, one approach that web service providers can use isto employ user identification systems to collect data to form userprofiles, and the web service providers can use this data to personalizethe content and form of their services (e.g., through dynamic web siteimplementations that can customize content delivered to users based onsuch user profiles).

To identify users, web service providers have traditionally relied onthe user's signing or logging into the web site in order to access theweb site. Sign-in/log-in based authorization on its own is generallyvery restrictive in that it will often only identify a fraction of usersto a web site (e.g., as further discussed below, due to the fact thatmany users opt to browse a web site without signing/logging into thatweb site, such as for users that have not created sign-in credentials onthat site, and this also often occurs in cases in which such users havesign-in credentials for that site, but elect not to sign-in due to userconvenience or other reasons).

Specifically, the sign-in (e.g., also referred to as log-in) basedauthorization approach applied by web service providers generally doesnot provide sufficient user related data for at least the followingreasons.

First, users can visit web sites anonymously. In particular, users oftenvisit web sites anonymously, that is, without signing-in. As a result,it is difficult for such web sites to identify these users. Althoughthis problem is not limited to any particular device type (e.g.,desktop, laptop, tablet, phablet, smart phone, or another device type),it is generally a more prevalent issue for users browsing web sites ontheir mobile devices (e.g., tablets, phablets, smart phones or othertypes of mobile phones, and other types of mobile devices).

Second, users can have more than one device. With the proliferation ofInternet connected devices, a single user may use many devices (e.g.,tablet, home computer/laptop, work computer/laptop, mobile phone, smartTV, and/or other devices). As a result, users may browse content and,thus, create data for a user profile across such devices. However, thisinformation can be valuable in generating a complete profile of theuser.

Specifically, the combination of these two problems means that without auser sign-in on each device, a service provider (e.g., a web serviceprovider) will not be able to determine that the user behind themultiple devices is the same user or is likely the same user.

More specifically, an inability to be able to identify users createsseveral different problems for the web service provider. The inabilityto be able to identify users makes it difficult for the service providerto personalize or customize the web site for each user. For example, theservice provider cannot effectively provide customized content for theuser if the service provider cannot identify the user across devices(e.g., user platform). Furthermore, the site provider cannot connectuser activity across devices to create user profiles. As a result, atypical approach is for service providers to simply attribute actions todevices instead of users (e.g., users that can be associated with two ormore devices). For many service providers, these user profiles willcontinue to be split across devices if users are not signed in on eachdevice that they use to access the service (e.g., to access the serviceprovider's web site).

Further, web services providing online content (e.g., dynamic or othercustomized content for a web site) can be customized to providedifferent content to different users. However, as discussed above,customizing online content based on users is not effective if the usercannot be identified (e.g., a user that did not log into the webservice), and the user accesses the web service from two or moredevices.

In a common scenario, assume that a user, named Bob, browses a webservice, such as ACME.com, during a session from Bob's smart phonewithout logging into the web service (e.g., anonymously browsing a website of the web service without using a sign-in or other basedauthorization technique). In this scenario, Bob and Bob's smart phoneare typically just associated using an identifier (ID) via a cookieassociated with that session (e.g., cookies can be stored past a givensession, that is, cookies can be persistently stored, in this example,on Bob's smart phone). However, Bob would not be identified as the sameuser when browsing that web service, which is ACME.com in this example,using a different user platform/device, such as from Bob's laptopcomputer. In such cases, the web service, ACME.com, cannot customizecontent for Bob that is uniquely identified, such as when Bob isbrowsing ACME.com anonymously from a different device, such as Bob'slaptop computer. Moreover, this inability to identify users who accessweb services anonymously across different devices/user platforms alsoresults in a fragmented data set for user profiles for such webservices. As a result, this also creates challenges for the web servicesto accurately and effectively customize content and associatedinformation that web services desire to generate, for example, variouse-commerce related metrics, such as lifetime value of a user, and/orvarious other e-commerce related activities, such as user profile-basedtargeted advertisements or targeted service/product offerings.

Thus, what are needed are techniques for identifying users of a website(s) even if the user has not signed into the web site, including forusers that access such web site(s) from multiple different devices/userplatforms.

Accordingly, techniques for cross platform user joining are disclosed.

In some embodiments, by using various signals, such as Internet Protocol(IP) addresses, in joining users across platforms, this technique offersincreased coverage of joined users and more complete user profiles(e.g., provides additional information by associating two or more, insome cases, anonymous user profiles). In particular, this technique doesnot rely solely on sign-in authentication to identify a user (e.g., insome cases, the exact user is not identified, but an anonymous userprofile across platforms can be created using various techniquesdescribed below, and as further discussed below, in some cases one ormore anonymous user profiles can be joined with a user identified userprofile using sign-in, user provided information, and/or othertechniques).

In some embodiments, cross platform user joining includes associating afirst user identification (UID) and a second UID with one or moreInternet Protocol addresses (IPs); associating the first UID and thesecond UID with one or more monitored behaviors; and joining the firstUID and the second UID based on the one or more IPs and the one or moremonitored behaviors.

For example, the first UID can be associated with a first set ofmonitored behaviors, and the second UID can be associated with a secondset of monitored behaviors. Also, the first UID can be associated with afirst user platform, and the second UID can be associated with a seconduser platform. In some instances, the first UID can be associated with afirst mobile device, and the second UID can be associated with a secondmobile device, and at least one of the first UID and the second UID cancorrespond to an anonymous UID.

In an example implementation, the one or more monitored behaviors can betracked using a pixel log. In addition, the one or more IPs are trackedusing a pixel log.

In one embodiment, cross platform user joining further includesmonitoring user browsing activity on a web site to associate two or moreanonymous user profiles. In particular, in order to associate two ormore anonymous user profiles, various techniques for cross platform userjoining are disclosed herein. For example, in order to monitor userbrowsing activity on a web site, pixel logs can be implemented on theweb site. Additionally, various algorithms for cross platform userjoining can be applied to determine which of a set of anonymous profilescan be joined (e.g., and with a determined confidence/probabilitylevel). As a result, such cross platform user joining can provide theweb site service provider the ability to provide customized contentand/or targeted web services to the user browsing the web siteanonymously based on the enhanced user profile data. In someimplementations, a cloud service provides suggested/customized webcontent for subscribing merchant web sites (e.g., suggestedcontent/products/categories, etc.) based on a joined user profile to thesubscribing merchant web sites for presentation to the user associatedwith the joined user profile.

As an example, assume that ACME Company is a company that sells asignificant variety of products (e.g., clothing, electronic, hardware,home related, and other products) online using an ACME Company web site,which is ACME.net. Also, assume that in a first session, Alice isanonymously browsing the ACME.net site from her smart phone web browserand that she is browsing the ACME.net site (web site) for a potentialpurchase of a new digital camera. Next, assume that in a subsequent,second browsing session, Alice is anonymously browsing the ACME.net sitefrom her tablet. Using the various cross platform user joiningtechniques described herein, Alice's earlier anonymous browsing session(e.g., in which in this example, Alice was viewing new digital camerasfor sale on the ACME.net web site) can be associated with her subsequentanonymous browsing session on a different device, in this example hertable, to provide customized web content targeted to Alice during hersecond anonymous browsing session (e.g., based on her associated earlieranonymous browsing session by joining such anonymous user profiles, thatis, even though such sessions are/were anonymous user browsingsessions). In this example, during Alice's second anonymous browsingsession, the ACME.net web site can determine one or more digital cameraproducts on their web site to output, for example, a listing of such oneor more digital camera products to display as output to Alice during hersecond anonymous browsing session (e.g., as suggested products, asrecommended products, as featured products, as special offers, as a homepage listing of products, as product advertisements, and/or in someother form of targeted/customized web content displayed to Alice duringher second anonymous browsing session on ACME.net). This approachfacilitates a more 1:1, user customized web services experience, asopposed to existing approaches that cannot associate anonymous userprofiles to offer customized web services, and as opposed to a typicalbrick and mortar shopping experience, in which all users see the sameproduct offerings when walking into a brick and mortar store. Suchproducts would not be displayed using typical approaches based on prioruser product page views or purchases on the merchant's web site, becausesuch products were not previously viewed during Alice's second anonymousbrowsing session on her tablet device and prior approaches would nothave associated Alice's first anonymous browsing session with her secondanonymous browsing session (e.g., or if just one of those browsingsessions were anonymous, prior approaches would not have been able tohave joined such user profiles). These and other examples illustratingapplications of cross platform user joining techniques are furtherdiscussed below.

In one embodiment, cross platform user joining further includesgenerating a joined user profile based on the first UID and the secondUID. In one embodiment, cross platform user joining further includessending the joined user profile to a web service. For example, the webservice can customize content and/or personalized content presented bythe web service to a user based on the joined user profile.

In one embodiment, cross platform user joining further includesdetermining a number of UIDs associated with each of the one or more IPsto categorize each of the one or more IPs (e.g., to provide an IP-basedsignal that provides more information based on the categorization of theIP address, such as whether the IP address is associated with a home IPaddress, a small/retail business IP address, a corporate IP address,and/or some other categorization(s)). For example, cross platform userjoining can be determined using categorized IPs that are associated withcertain UIDs.

In one embodiment, cross platform user joining further includesdetermining an intersection of relatively uncommon behaviors tofacilitate an association between the first UID and the second UID. Forexample, in addition to IP address signal input analysis forimplementing cross platform user joining, various techniques can beimplemented to improve a confidence level in the association (e.g.,joining) of the first and second UIDs by observing additionalcommonalities in behavior signals associated with the paired users(e.g., associated/joined UIDs), as further described herein with respectto various embodiments. Example behavior signals can include similarityin content of web pages visited (e.g., similar product pages on amerchant's e-commerce web site); similarity in channels the user entereda site from, such as identified via a referral URL (e.g., email, organicsearch, paid search, direct, etc.); similarity in queries on an internalsite search; a time window in which similar user activities on a sitewere monitored; a navigational pattern (e.g., a pattern of browsing orsearching, such as a user visiting a merchant site and searching forshoes using the site's internal search option as opposed to navigatingto a particular product category or a sales category, etc.); and/orvarious other behavior signals (e.g., monitored using a pixel log orother techniques for monitoring user activities on a web site), asfurther described herein with respect to various embodiments.

In some implementations, pixel logs can be used to gather user activitydata that can be associated with anonymous user profiles that can bejoined using various techniques for cross platform user joining. Forexample, these pixel logs can be analyzed to determine incoming traffic(e.g., clicks, such as a clickstream of user activity on a site) fromweb sites (e.g., e-commerce merchant web sites, e-mail web sites, socialsites/channels, news sites, and/or various other types of web services)and what items in particular were selected (e.g., clicked on) while theuser browsed such web sites. Also, such pixels can use cookies to atleast identify such tracked user activity with an anonymous useridentification (UID) stored persistently on the user's device. Pixellogs or web logs can be used to monitor various types of user behavior(e.g., to provide behavior signals associated with a UID), such as oneor more of the following: web pages visited; channels from which a userentered a site, which can be identified via a referral URL/URI (e.g.,email, organic search, paid search, direct, etc.); queries entered by auser on an internal site search; a time on which a user browses a siteor a particular web page or other content on a site; an IP addressassociated with a user's device from which the user is accessing a site;and a navigational pattern (e.g., pattern of browsing or searchingperformed by a user on a site). As would be apparent to those ofordinary skill in the art, various pixel log implementations can beprovided and/or similar or other approaches can be implemented formonitoring user activities on web sites.

In one embodiment, cross platform user joining further includes applyingvarious other behavior signals in an analysis of which UIDs can bejoined based on a probability determination that such UIDs can beinferred to be associated with the same user across two or moredifferent devices. For instance, additional types of signal input canalso be used to make the cross platform user joining determinations,including, for example, sign-in by users to one or more sites, e-mail, asave for later e-mailed link to a site (e.g., in which a user can emaila link to web content to their own email account to view at a latertime, possibly using a different user platform/device), referral URL,user input, and/or various other information, as further describedherein with respect to various embodiments.

As further described below, these and various other features andtechniques are disclosed for providing cross platform user joining.

Overview of an Example Cross Platform User Joining Service

FIG. 1 is a block diagram illustrating an overview of an architecture ofa system for providing cross platform user joining in accordance withsome embodiments.

As shown, various user devices, such as a laptop computer 102, a desktopcomputer 104, a smart phone 106, and a tablet 108 (e.g., and/or variousother types of computing devices that can access the Internet to browse,for example, various types of web sites) are in communication withInternet 140 to access various web sites provided by different webservers 130A, 130B, . . . , 130N (e.g., which can each serve one or moreweb sites).

For example, the web servers can each provide a web site, such as amerchant's web site that can offer various products and/or services forsale from the merchant and/or various other types of web sites. Each ofthe web sites can also include dynamic content that can be used tocustomize/personalize various content of the respective web site for auser accessing/browsing the web site (e.g., based on a useridentification or a user profile). For example, users can generallybrowse the web site, in some cases from different devices, to viewand/or access different content available on the web site, in some casesanonymously browsing the web site.

The web servers can also subscribe to a cross platform user joiningservice 120 (e.g., which can be provided as a cloud-based cross platformuser joining service for web sites). In some implementations, the crossplatform user joining service provides various techniques foridentifying users across devices, even if such users are accessing theweb sites anonymously and using multiple different/distinct devices toaccess the web sites, as disclosed herein.

In particular, a web server can communicate with the cross platform userjoining service to receive information regarding user activitiesperformed on the web site to the cross platform user joining service(e.g., as a user activity feed, and/or in some other format, using anAPI or other mechanism for communications over the Internet between theweb server and the cross platform user joining service, such as usingsecure data communications). The cross platform user joining service cancommunicate, for example, joined UIDs as a data feed to the web site. Asa result, this joined UIDs data feed can be applied by the web site togenerate customized/personalized web content for presentation to a userassociated with a joined set of UIDs.

For example, assume that Alice was anonymously browsing for digitalcameras on an electronics consumer review web site while she was usingher smart phone. Assume that Alice had previously visited (anonymously)that same electronics consumer review web site when she was on her workcomputer. The UIDs for Alice on those two different user platforms canbe joined using various cross platform user joining techniques disclosedherein, and the cross platform user joining service communicates thedetermination of these joined UIDs to the electronics consumer reviewweb site. As a result, when Alice is visiting that same electronicsconsumer review web site the following day on her work computer, theelectronics consumer review web site can utilize that joined UIDsdetermination received from the cross platform user joining service toprovide customized content to Alice, such as suggesting a new digitalcamera review article or by presenting targeted advertisements to Alice.

In some implementations, the cross platform user joining service can beimplemented on a computer server or appliance (e.g., or using a set ofcomputer servers and/or appliances) or as a cloud service, such as usingAmazon Web Services or other cloud service providers. For example, crossplatform user joining service 120 can be implemented on one or morecomputer server or appliance devices or can be implemented as a cloudservice, such as using Amazon Web Services or another cloud serviceprovider for cloud-based computing and storage services.

FIG. 2 is a functional block diagram illustrating a cross platform userjoining engine in accordance with some embodiments. As shown, a crossplatform user joining engine 202 includes a CPU 204, a RAM 206, and adata storage 208. For example, cross platform user joining engine 202can be implemented on the cross platform user joining service 120 asshown in FIG. 1.

As also shown in FIG. 2, cross platform user joining engine 202 includesan IP processing component 210 (e.g., to process, and in some cases,categorize IPs that are identified as associated with one or more UIDsas further described herein), a behavior signal processing component 212(e.g., behavior signal data can be provided for subscriber/monitored websites by using click logs/pixel tags data for monitoring user activitiesduring a session to provide a user's browsing history, including anyreferral URLs associated with a product(s) on a web site, user profiledata to provide information about a user including a user's explicitpreferences, and/or other behavior signal data as described herein),other signal processing component 214 (e.g., for processing additionalsignals, such as save for later email signals, user input signals, userlogin signals, and/or various other signals as further discussed below),and a UID joining processing component 220 (e.g., for determining whichUIDs to join for providing cross platform user joining based on inputreceived from IP processing, behavior signal processing, and/or othersignal processing components). The processing performed by each of thesecomponents is further described below. In some implementations, one ormore of these functions can be performed by another device or function,such as the behavior signal processing and/or the other signalprocessing can be performed using another device or function, which canprovide respective input to the cross platform user joining engine. Asanother example implementation, various components can be implemented asa common component, such as a behavior processing component can beimplemented to receive and process both behavior signals and othersignals. In some implementations, the cross platform user joining engineis implemented using the Apache Solr open source framework as furtherdescribed below with respect to FIG. 3.

For example, cross platform user joining engine 202 can implement thecross platform user joining service 120 described above with respect toFIG. 1. For example, a cross platform user joining determination for aset of UIDs can be processed using CPU 204 and RAM 206 to automaticallygenerate a joined set of UID results that can be stored in storage 208and communicated to a web site that subscribes to cross platform userjoining service 120 for presenting to a user via the user's web browserexecuted on the user's device.

Overview of Cross Platform User Joining Techniques

FIG. 3 is a functional diagram illustrating an architecture forIP-based, behavior signal, and other signal processing for providingcross platform user joining in accordance with some embodiments. Forexample, this architecture for IP processing, behavior processing, andother signal processing shown as 302 in FIG. 3 can be used to implementprocessing components shown as 210, 212, and 214 of the cross platformuser joining engine illustrated in FIG. 2.

Because user activity can happen across multiple devices as users canaccess web sites from one or more devices (e.g., from their homecomputer, from their work computer, from their mobile phone, etc.), thisinformation that is otherwise spread across different user devices canbe collected and aggregated in a centralized or common data store foranalysis and processing. For example, once a user identification (UID)join is identified for a set of two or more UIDs, the data for such UIDscan be merged resulting in a reduced set of unique UIDs. In addition,these users can be further clustered based on session/behavior analysis,which provides behavior signal input (e.g., monitored user activities,such as browsing behavior, navigation patterns, etc.) resulting in userprofiles that can be used for example as shown in FIG. 3 as furtherdescribed below.

Referring to FIG. 3, pixel logs data input 304 is received at UIDcorrelation based on IP (e.g., IP address information) 306. For example,UID correlation based on IP 306 can process such received IP addressinformation to correlate UIDs with such IPs. In some cases, other signaldata, such as email related data, user provided data, save for laterdata (e.g., save for later in which an email link to a web page is sentby a user to access that web page later possibly from another device,such as when a user emails a unique link to an article when accessing aweb site from their mobile phone but would rather view later on theirtablet or computer), and/or other input can also be received via pixellogs 304, which can also be used for performing UID correlation withIPs.

As also shown, pixel logs data input 308 is received at session analysis310 (e.g., for behavior analysis). For example, session analysis 310 canextract various session/behavior related data parameters (e.g., browsingactivity, navigation patterns, and/or various other monitored useractivities, such as described herein), associating the extracted varioussession/behavior related data parameters with corresponding UIDs.

As shown in FIG. 3, one use case of merged profiles of users acrossdevices are then provided as input into a search platform, such as anApache Solr open source search platform (e.g., or another open source orcommercially available search platform can be used), to servepersonalized results to each profile in accordance with someembodiments. Specifically, at 312, user data received from UIDcorrelation based on IP, email 306 and session analysis 310 can bemerged. At 314, such users can be clustered into user profiles (e.g.,various clustering techniques are further described below). At 316, theApache Solr platform can also be used to provide user preferences basedon the clustered user profiles (e.g., to associate common usersession/behavior data parameters with clustered user profiles).

In one embodiment, UIDs can be joined based on one or more of thefollowing techniques: Internet Protocol (IP) address; behavior relateduser activities; and/or other signals. For example, other signals forproviding cross platform joining can include one or more of thefollowing: sign-in information (e.g., using HTTP, HTTPS, or othernetwork and/or authentication protocols); user provided data (e.g.,contact information); email; save for later (e.g., a special casediscussed further below); and machine learning algorithms (e.g., whichcan enhance and/or provide new approaches or signals for providing crossplatform user/UID joining). Each of these techniques for performing UIDjoining are discussed in more detail below.

Internet Protocol (IP) Address-Based Joining

FIG. 4 is a graph diagram illustrating an association of IP addressesand UIDs for providing cross platform user joining in accordance withsome embodiments. For example, a bipartite graph can be used toillustrate a relationship between one or more IP addresses (IPs) withone or more user identifiers (UIDs).

Consider a scenario in which a user uses multiple different devices overhis/her home Wi-Fi network (e.g., a laptop, a tablet, a mobile phone,and/or other devices). All of these devices will typically share thesame external IP address (e.g., accessing the Internet via that samehome Wi-Fi network, such that will have the same IP address for eachsession accessing, for example, a web site, regardless of which devicethe user is using to access a given web site during a particularbrowsing session). However, the user's cookie (e.g., set by the website, which can be persistently stored on a user's device) on all thesedevices will be different. The unique cookie stored on each devicecorresponds to a user identifier (UID). At the same time, as a usermoves from one place to another (e.g., home to office and/or to anotherlocation), his/her IP address will generally change; however, the cookie(e.g., which corresponds to a UID) on the machine will remain the same.

This type of example scenario can be illustrated using a bipartite graphof the form as described below, in which the UID as used in this exampleis synonymous to a cookie in the pixel logs. In this example, assumethat IP1 corresponds to the IP address at this user's home, IP2corresponds to an IP address at this user's office, and IP3 correspondsto an IP address at a local coffee shop that is visited by this userthat has a local Wi-Fi that can be used by customers of the coffee shop(e.g., a free Wi-Fi access point).

Also assume that UID1 has been associated with IP1, IP2, and IP3; UID2has been associated with IP1 and IP2; UID3 has been associated with IP3;and UID4 has been associated with IP2. In this example, a UID (e.g.,associated with a user's device) can be associated with an IP address ifthe device associated with that UID is monitored accessing a siteassociated with that particular UID from that given IP address of theuser's session. These IP to UID relationships in this example areillustrated in the bipartite graph shown in FIG. 4.

The following relations can be inferred across UIDs from the bipartitegraph of IPs versus UIDs. In this example, UID1 is inferred to berelated to UID2, UID3, and UID4; UID2 is inferred to be related to UID1and UID4; UID3 is inferred to be related to UID1; and UID4 is inferredto be related to UID1 and UID2.

Analysis of the directed graph representation as shown in FIG. 4 willlead to identifying an anonymous user profile across all devices thatshare the same IP address and then extending this to multiple IPaddresses based on overlapping cookies.

In an example implementation, the IP address-based joining of the userscan be placed into one of three buckets for an approximate calculation(e.g., to apply a confidence level based on number of users associatedwith a given IP address, in which a more privately shared IP address canprovide a higher confidence/probability than a more publicly shared IPaddress for performing cross platform user joining) as described below.

Household Private IP: if the IP address is shared by, for example, 1-4devices, the cross platform user joining service can reliably infer thatit is either the same user or at least the same household.

Small—Medium Group IP: if the IP address is shared by 5-20 people, mostlikely these people have some common interests, demographics, and/orother aspects or attributes that can be reasonably inferred by the crossplatform user joining service. For example, such persons may be part ofthe same Small/Medium Business (SMB) or may be frequent visitors of thesame coffee shop or another location.

Public IP/Corporate IP: if an IP address is shared by more than, forexample, 21-100+ users, it generally provides less information than canbe reliably inferred by the cross platform user joining service. In thiscase, either the observed IP address belongs to an Internet ServiceProvider (ISP) or some large entity (e.g., a large corporation, agovernmental organization, or another large entity). In such cases, theIP address can be ignored by the cross platform user joining service.

As will be apparent to those of ordinary skill in the art, these rangesof numbers of devices can vary and are generally a continuum that can beused for categorization that can be associated with different inferenceswith different confidence levels as further described below.

In some implementations, the cross platform user joining service usesUID and IP data collected across multiple different sites, such ase-commerce merchant web sites, news web sites, social networking websites, email web sites, and/or other types of sites.

In some implementations, merchant/other web site provider data sets andexternal data sets can be used to supplement this categorization (e.g.,to provide more information regarding IP addresses for enhanced IPaddress categorizations). For example, web log data (e.g., web log datacan include pixel log data) that is collected and analyzed across aplurality of merchants/other web site providers can be used to implementenhanced IP address categorizations. In some cases, data from serviceproviders regarding IP addresses can be used to supplement thesetechniques to make more refined inferences (e.g., ISPs and/or otherthird party service providers that provide various information regardingallocated IP address information). For example, if an Internet ServiceProvider (ISP) provides IP address data that indicates that IP2 is acoffee shop or other small retail enterprise, then that additionalinformation can be used by the cross platform user joining service toperform a more reliable inference (e.g., on how likely it is, howprobable it is) on whether UIDs associated with that IP2 are (likely)associated with the same user.

Cross Platform User Joining System Architecture

FIGS. 5A and 5B are functional block diagrams illustrating overviews ofan offline architecture and an online architecture of a system forproviding cross platform user joining in accordance with someembodiments.

Building on this example, in some embodiments, a solution includes thefollowing operations that can be automatically performed by a serviceand/or a system for cross platform user joining (e.g., a cross platformuser joining service, such as described above with respect to FIG. 1,and/or a cross platform user joining engine, such as described abovewith respect to FIG. 2), which can perform a process such as shown inFIGS. 5A and 5B.

In some implementations, additional information, such as behaviorsignals, can be applied to increase confidence in cross platform userjoining based on IP addresses. For example, user behavior can also bemonitored to further refine the categorization/inferences of UIDs basedon IP addresses, such as by associating common events across UIDs (e.g.,monitored behavior, such as various user activity, including, forexample, browsing for men's running shoes, or browsing for women'srunning shoes, browsing sale sections of e-commerce merchant sites,viewing a news web site's home page versus viewing a news web site'sparticular international news section, versus tracking a particularauthor, versus browsing a particular article, etc.). As furtherdescribed below, these techniques attempt to identify events that arerelatively unique events that are common between a set of UIDs.

Referring now to the offline method as shown in FIG. 5A, as shown atstep 1 of FIG. 5A, a user visits a service provider on multipleplatforms. For example, a user executes a browser 502 on a user platform(e.g., a user's local client device) to access a web site 506 via theInternet 504. In this example, the web site service provider creates apersistent first-party cookie to assign a unique identifier (UID) to theuser's device that the user is using to access web site 506. This cookieand UID allows the server to continue to identify the device in laterweb sessions (e.g., the cookie is persistent).

As shown at step 2 of FIG. 5A, a web log collects critical data (e.g.,using pixel log data) on the information each unique user profile makesand receives (e.g., using a platform for cross platform user joiningthat can receive pixel log data from browser 502). As an example, for ane-commerce site, such information can include the following: IP address,what parts of a web site a user clicks on, when a user chooses toinclude an item in the shopping cart, purchase an item, and othershopping actions, registration events, viewing of products, paymentactions, and/or other activities.

As shown in Step 3 of FIG. 5A, user data collected from the web log foreach device is stored in a data store (e.g., a storage device), shown asa data storage 508. In particular, each device is associated with itsunique cookie/unique identifier (UID). The user data associated witheach UID can be queued for analysis at queue 510, classified using anApache Hadoop framework to provide a classification engine 512 (e.g., orother open source frameworks or other commercially available solutionsfor providing large data set analysis can be used for the classificationengine), and the multiple signals can be analyzed to determine whether amatch is determined, such as based on a sign-in match 514, an emailmatch 516, and/or an IP match 518, as further discussed below withrespect to step 4.

As shown at step 4 of FIG. 5A, a list of IPs that the device/UID hasbeen observed accessing the web service is determined using variousengines for cross platform user joining, including a sign-in matchengine 514, an email match engine 516, and/or an IP match engine 518(e.g., the cross platform user joining engine as described above withrespect to FIG. 2).

For example, for each IP address, the following operations can beperformed as described below. A search operation can be performed acrossweb logs to find other UIDs that have connected to the web site usingthat IP address. A determination of a number of devices that haveconnected using that IP address over a particular time period (e.g., inthe past week or another time period) can be performed. Next, aprobability can be calculated and assigned that the pairs of users foundon that IP are the same user. In this example, high probability pairs ofthe type A:B, A:C can be used to form clusters of users that are highlysimilar to A:B:C, which can then have a probability that the user isagain the same. In particular, a methodology and various factors fordetermining probability are further described below. At this stage ofprocessing, the processing can proceed to a next IP address. Email andother signals for facilitating cross platform user joining are alsofurther described below.

Referring now to the online method as shown in FIG. 5B, for new users,the cross platform user joining engine can associate a new UID with aset of related users, based on already existing attributes of otherusers stored in a user attribute mapping database 554 and the knownattributes of the new user received from the visited site 552. As shown,when a new user 550 visits site 552, new user attributes can be sent touser attribute mapping 554. At step 5 of FIG. 5B, based on the new userattributes received from the visited site and based on already existingattributes of other users stored in a user attribute mapping database554, a Map Reduce processing operation is performed at step 5 as shownto determine a list of related users provided in a related users dataset/store 556.

Thus, using these techniques, the cross platform user joining servicecan generate a list of devices/UIDs that are likely to belong to thesame user profile and assign a confidence level to that match.

IP-Based UID Joining

FIG. 6 is a functional diagram illustrating an architecture for IP-basedUID processing for providing cross platform user joining in accordancewith some embodiments. For example, this architecture for IP-based UIDprocessing shown as 602 in FIG. 6 can be used to implement UIDs joiningprocessing component shown as 220 of the cross platform user joiningengine illustrated in FIG. 2.

As shown in FIG. 6, IP-based UID joining can be provided to servepersonalized results to each user profile (e.g., joined UIDs) inaccordance with some embodiments. As discussed below, the IP-based UIDjoining process can combine IP data with other behavior analysis signaldata (e.g., user clickstream-based signals and/or other behaviorsignals) to merge UIDs to create pairs of users along with confidencemeasurements, as further described below.

Referring to FIG. 6, pixel logs data input 604 is received at IP, UIDmapping component 606. For example, the IP, UID mapping can beimplemented using a Map Reduce (MR) (e.g., also commonly referred to asMapReduce) processing operation(s). The result of this IP, UID mappingis a generation of a bipartite graph 608 (e.g., providing an IP versusUID bipartite graph, such as shown in FIG. 4 as discussed above).Bipartite graph 608 is provided to a UID similarities component 610 fordetermining a mapping of (likely) related/associated UIDs at 612. TheUID to UID relationship mapping result 612 is provided to merge UID,behavior data component 620.

As also shown, pixel logs data input 614 is received at UID/behavioranalysis component 616. For example, UID/behavior analysis component 616can determine an association of various behaviors (e.g., products,categories, search terms, etc.) to each UID, which can be implementedusing a Map Reduce (MR) processing operation(s). The result of this UIDto behavior(s) relationships result 618 is also provided to merge UID,behavior data component 620.

Merge UID, behavior data component 620 receives input 612 and 618 andmerges the received UID and behavior data to generate merged UID,behavior data results 622. The merged UID, behavior data results 622 areprovided as input to a cluster UIDs component 624 (e.g., which can alsobe implemented using a Map Reduce operation(s)). Also, at 624, one ormore machine learning algorithms can be implemented to facilitate theclustering operation(s). Various machine learning algorithms that can beused to implement the clustering operation(s) are further describedbelow.

Calculating Probability/Confidence with Behavior Data

In addition to using the pure IP address signal, the cross platform userjoining engine can enhance the confidence in the joining of UIDs (e.g.,pairing of users) further by observing additional commonalities in thebehaviors (e.g., clickstream) of the paired users/joined UIDs.

For example, this probability can be computed as shown below.

Given that two devices exist each with the following UID to event (e.g.,behavior event) relationships, the probability that two distinct UIDsare associated with the same user can be expressed as follows.

UID₁ is associated with events(E_(n1) . . . E_(n2))

UID₂ is associated with events(E_(n2) . . . E_(n4))

E_(1,2) is the set of common events between UID₁ and UID₂

P(UID_(a),UID_(b) are same user)=P(2 random UIDs have E _(1,2) incommon|(n2−n1)events for one UID and (n4−n3)events for the other UID)

For example, probabilities can be calculated by the same cross platformuser joining engine periodically sampling historical behavior signaldata.

In an implementation using Monte Carlo simulations, the cross platformuser joining engine can then compute the likelihood of the users to bethe same. For example, user history can then be determined using theweighted average of the probabilities associated with each UID and theirrespective user history as shown below.

${{Events}\mspace{14mu} {for}\mspace{14mu} U\; I\; D_{1}} = {\sum\limits_{n = 1}^{n}{{P\left( {{U\; I\; D_{1}},{U\; I\; D_{n}\mspace{14mu} {are}\mspace{14mu} {same}\mspace{14mu} {user}}} \right)}*{Events}\mspace{14mu} U\; I\; D_{n}}}$

This weighted average set of events can then be used for furtherupstream algorithms that receive UID₁ history as an input (e.g., apersonalization algorithm, such as for providing personalized orcustomized content on a site to a given user).

For example, if the devices/UIDs identified as potentially belonging tothe same user both show visits to the same page on a site (e.g., anevent in common), then the cross platform user joining engine canautomatically join the users together with higher confidence. Further,if the probability of two users picked at random having visited thatpage is relatively low, then the cross platform user joining engine canautomatically determine with increased confidence that the user acrossthe devices is the same user. That is, this probability determinationfacilitates determining relatively unique events to assist in crossplatform user joining based on using behavior data (e.g., relativelyunique common set of events, such as when UID₁ and UID₂ are monitored toboth have visited a common set of international news stories related toa particular country and news stories by a particular author on a newssite, as opposed to UID₃ and UID₄ both visiting a home page of a popularnews site).

Similarly, the cross platform user joining engine can use one or more ofthe other characteristics to determine the probability that two distinctUIDs belong to devices of the same user. For example, thesecharacteristics can include one or more of the following: similarity incontent of web pages visited (e.g., similar product pages); similarityin channels a user entered site from, such as identified via a referralURL (e.g., email, organic search, paid search, direct, etc.); similarityin queries on internal site search; a number of common IP addresses; atime window in which these similar actions were seen; a geo-location ofthe set of IP addresses associated with the UIDs (e.g., ISPs and otherservices provide a mapping of IPs to geo-locations); and a navigationalpattern (e.g., pattern of browsing or searching, such as visiting amerchant's web site and searching for shoes as opposed to navigating toa particular product category versus an on sale category, etc.).

In some embodiments, additional information can be used based on userprovided data, such as login, forms input, and/or other user provideddata, as is now further described below, including sign-in based UIDjoining, user information-based UID joining, email-based user joining,and save for later-based UID joining, each discussed in more detailbelow.

Sign-In Based UID Joining

If a user signs into multiple devices, the cross platform user joiningengine can automatically join the UIDs (e.g., cookies) across thesedevices based on the user's login information. If the sign-in happens tobe behind a secure login (e.g., a login using HTTPS or another secureauthentication protocol), web site service provider data can assist thecross platform user joining engine in joining such users. For example,merchant provided data can be communicated to the cross platform userjoining engine, in which that merchant provided data includes anidentification of the user's identity based on the user logging into theweb site (e.g., which can be securely provided to the cross platformuser joining engine using above-described communication mechanisms thatallow for secure communications between the merchant's web site serverand the cross platform user joining service).

In some cases, sign-in for a site may be with or without passwordauthentication. Other forms of sign-in can include providing an emailaddress, a social networking site login (e.g., Facebook®, LinkedIn®,Google®, or other social networking sites), a federated login service(e.g., OpenID or other federated login services), and/or other types ofsign-in operations, which can similarly be used to implement thissign-in based UID joining.

User Provided Information-Based UID Joining

Similar to sign-in based UID joining techniques, the cross platform userjoining engine can accept user entered information on a web site/webservice to join users. For example, credit card, addresses, phonenumbers, and other contact information entered by the user can be usedto link a UID on a particular device to other UIDs (e.g., suchinformation can be monitored using pixel logs while a user isinteracting with the web site/web service, such as from entry data,etc.).

Email-Based UID Joining

Similar to IP address-based UID joining techniques, the cross platformuser joining engine can automatically identify users across platformsthrough their interaction with email. For example, anytime an email isopened on multiple devices, the cross platform user joining engine canjoin the user across these devices/UIDs if the email link contains aunique identifier or code specific to that user. In some cases, certainservice providers can provide this information as part of a referral URLthat can be monitored using a pixel log.

Special Case—Save for Later-Based UID Joining

Save for later-based UID joining is an example special case. This caseinvolves promoting emails that allow users to, for example, emailthemselves a link to a product to later purchase that product on desktopand/or to later view that web content such as an article at a later timepossibly on a different device.

For example, consider the following process flow for this use casescenario. A user browses a web site on the user's first device, such asthe user's mobile phone. The user would like to bookmark certain itemsto view later on another device, such as their laptop or tablet. In thisexample, the user can select those items and send those to their emailaddress to view later on another device. The email can include a uniquelink that when opened on another device will allow the user to accessthese items. Because the link is unique, if the user accesses it onanother device, that unique link can also be used by the cross platformuser joining engine as a signal (e.g., monitored using a pixel log oneach device) to identify other devices the user may use.

As a result, such a feature can allow a user to save items for later andcan be used as a signal by the cross platform user joining engine injoining users across devices—UID joining. As another example, a user ofa news web site can share a news article that was viewed by the userfirst on their mobile phone by emailing a link to that article tothemselves, and then the user can choose to save for later that newsarticle so that the user can view this article on another device, suchas their tablet at a later date by clicking the link in the email. Thesetechniques can then be used to associate the UIDs of that user's smartphone and that user's tablet.

Machine Learning Techniques to Expand Coverage of UID Joining

Using the various techniques described above, users across devices(e.g., UIDs) can be automatically merged at different confidence levels.For example, using the high-confidence user joins, patterns/features canbe mined to learn what intrinsic features are exclusive tohigh-confidence user joins.

In some embodiments, machine learning classification algorithms can beimplemented to classify whether a pair of different UIDs belong to thesame user, and at what confidence level. For example, the training datafor such a machine algorithm(s) is based on high confidence matches thatcan be provided either from the IP join or through other joiningtechniques described herein (e.g., sign-in based joining).

Some of the features in such a machine algorithm(s) can include, forexample, one or more of the following: a number of common IP addressesthe two UIDs have browsed from; a number of common private IP addresses;a similarity between behavior signals (e.g., clickstreams) on thedifferent platforms using product/category page views; a similaritybetween behavior signals (e.g., using clickstreams) using search queriesweighted by the frequency of the common search queries; a probability ofcommon search queries or product/category page views in two randomlychosen behavior signals (e.g., using clickstreams); a similarity betweenbehavior signals (e.g., using clickstreams) using similarity of producttypes viewed; a time between the visits from the different platforms; alocation obtained from IP-based geo-location data; and differentsignatures of a particular visit (e.g., median time spent onproduct/category/search pages, and/or a shorthand representation of thestate transitions represented in the clickstream).

For example, based on one or more of these features, a machine learningalgorithm can seek to discover patterns in the training data set andapply those to new sets of users. Thus, these machine learningtechniques can lead to expanded coverage beyond just the joiningtechniques specifically described above.

As an example implementation, a machine learning based implementationcan learn related users as described below. For example, assume thatthere are N users stored in the database, and the objective is todetermine groups of related users (e.g., related UIDs). In this context,related users can be defined to be the same person accessing the site asdifferent users. The difference is manifested, because of the use ofcookies for tracking purposes (e.g., the same person can be allocateddifferent cookies or UIDs when, for example, accessing the site usingdifferent devices, such as their desktop computer and their mobiledevice). Hence, a person using a desktop computer and a mobile devicewill generally be classified as two different users (e.g., allocated twodistinct UIDs).

In this example, assume there are two users, A and B, whose attributesare represented as attributes(A) and attributes(B), respectively. Theprobability that A and B represent the same user can be computed asfollows:

${P\left( {{A = {B{{attributes}\mspace{11mu} (A)}}},{{attributes}\; (B)}} \right)} = \frac{P\left( {A = {B\mspace{14mu} {and}\mspace{14mu} {attributes}\mspace{14mu} (A)\mspace{14mu} {and}\mspace{14mu} {attributes}\; (B)}} \right)}{P\left( {{attributes}\; (A)\mspace{14mu} {and}\mspace{14mu} {{attributes}{\; \;}(B)}} \right)}$

Given a training data set of related users, the above probability can becomputed using, in some implementations, using a count. In this example,the training data can be in the form of pairs of users, A and B, andtheir attributes and a target label denoting if they are related usersor not.

As would now be apparent to one of ordinary skill in the art, the largerthe training data set, the more accurate would be the results forapplying such machine learning techniques to compute the above-describedprobabilities. In some implementations, in order to mitigate potentialinaccuracies based on the size of the training data set being used,various smoothing techniques can be implemented, such as theJelinek-Mercer smoothing, add-one smoothing, Katz back-off smoothing,and/or various other smoothing algorithms can be implemented. Inparticular, the use of such smoothing techniques facilitates an accuratecomputation of these probabilities even for smaller training data sets.

In some implementations, given the training data, the above-describedprobability computational problem can be posed as a standardclassification problem. As such, in some implementations, variousclassification algorithms can be used to provide a machine learningbased implementation that can learn related users, such as randomforests, Support Vector Machines (SVM), and/or various otherclassification algorithms as would now be apparent to one of ordinaryskill in the art.

Further, the above-described cross platform user joining system has apositive feedback loop in which the system learns continuously from theuser pairs that are merged using the various techniques describedherein.

Example Front-End Application of Cross Platform User Joining Engine

FIG. 7 is a screen diagram illustrating a graphical user interface (GUI)of a web interface for providing cross platform user joining inaccordance with some embodiments. In particular, FIG. 7 illustrates ascreen image 700 of a front-end display showing various product itemsoutput on an example merchant's web site. At 702, items that the userviewed on this device/user platform (not joined) are shown. At 704,items viewed on other unique devices/user platforms joined with highprobability are shown. In this example, a high probability can beinferred based on UIDs that have an IP match with this device/UID andalso have similar behavior(s) across such joined UIDs/devices (e.g.,and/or other cross platform user joining techniques can be implementedto determine a high probability, as described herein, such as a sign-inmatch, user provided information, and/or other techniques).

Further, this information accumulated about the user and joined userdata can be used in various forms. For example, recommendations and/orother customized/personalized content based on a user history that isprovided via joined user profiles can be presented to the user.

Various other formats and/or icons can be provided to provide a GUI forimplementing cross platform user joining as will now be apparent to oneof ordinary skill in the art.

Example Processes for Cross Platform User Joining

FIG. 8 is a flow diagram illustrating a process for providing crossplatform user joining in accordance with some embodiments. In someembodiments, the process for providing cross platform user joining isperformed using the cross platform user joining system/service, such asdescribed above with respect to FIGS. 1-7.

Referring to FIG. 8, at 802, associating a first user identification(UID) and a second UID with one or more Internet Protocol addresses(IPs) is performed. For example, the first UID can be associated with afirst user platform (e.g., a user's laptop), and the second UID can beassociated with a second user platform (e.g., a user's smart phone). Insome cases, at least one of the first UID and the second UID cancorrespond to an anonymous UID (e.g., the UID has not been associatedwith an authorized user sign-in).

At 804, associating the first UID and the second UID with one or moremonitored behaviors is performed. For example, a pixel log data streamcan be used to monitor user behavior, which is provided to a cross userplatform service for associating with UIDs.

At 806, joining the first UID and the second UID based on the one ormore IPs and the one or more monitored behaviors is performed. In someimplementations, a number of UIDs associated with each of the one ormore IPs is determined to categorize each of the one or more IPs. Insome cases, external data sources can be used to classify or categorizeIPs, such as described above.

For example, if a distinct set of UIDs are determined to be associatedwith two different IP addresses (e.g., both of which have beencategorized as being associated with private residences), and if thedistinct set of UIDs have also been associated with similar behaviorsignals, then the distinct set of UIDs can be joined, such as furtherdescribed below with respect to FIG. 9.

FIG. 9 is another flow diagram illustrating a process for providingcross platform user joining in accordance with some embodiments. In someembodiments, the process for providing cross platform user joining isperformed using the cross platform user joining system/service, such asdescribed above with respect to FIGS. 1-7.

Referring to FIG. 9, at 902, associating each of a plurality of distinctuser identifications (UIDs) with one or more IP addresses is performed.For example, a pixel log data stream can be used to monitor IPs, whichis provided to a cross user platform service for associating with UIDs.

At 904, associating each of the plurality of distinct UIDs with one ormore monitored behaviors is performed. In some implementations, avariety of behavior and other signals can be collected and associatedwith UIDs, as discussed above with respect to various embodiments.

At 906, joining a subset of the plurality of distinct UIDs based on theone or more IPs and the one or more monitored behaviors is performed.For example, if a subset of the plurality of distinct UIDs is determinedto be associated with a particular set of different IP addresses (e.g.,which have been categorized as being associated with privateresidences), and if the subset of the plurality of distinct UIDs hasalso been associated with common behavior signals that are determined tobe (relatively) unique to this subset of the plurality of distinct UIDs,then the subset of the plurality of distinct UIDs can be joined (e.g.,with a determined confidence level).

At 908, generating a joined user profile based on the joined subset ofthe plurality of distinct UIDs is performed. For example, user behaviorsmonitored with each of the joined UIDs can be associated with the joineduser profile.

At 910, sending the joined user profile to a web service, in which theweb service can customize content presented by the web service to a userbased on the joined user profile is performed. For example, using a userprofile based on a plurality of UIDs that have been joined based on suchcross platform user joining techniques, content on the web site can becustomized and/or personalized for presentation to the user based on thejoined user profile. In some cases, a recommended category of contentcan be displayed automatically or in response to a user request on a website.

In some implementations, a cloud service provides suggested/customizedweb content for subscribing merchant web sites (e.g., suggestedcontent/products/categories, etc.) based on a joined user profile to thesubscribing (merchant) web sites for presentation to the user associatedwith the joined user profile.

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the invention is not limitedto the details provided. There are many alternative ways of implementingthe invention. The disclosed embodiments are illustrative and notrestrictive.

WHAT IS CLAIMED IS:
 1. (canceled)
 2. A system for cross platform userjoining, comprising: a processor configured to: associate a first useridentification (UID) and a second UID with one or more Internet Protocoladdresses (IPs); associate the first UID and the second UID with one ormore monitored behaviors; and join the first UID and the second UIDbased on the one or more IPs and the one or more monitored behaviors,wherein the joining of the first UID and the second UID includes one ofthe following: A) determine whether a first set of monitored behaviorsassociated with the first UID is related to a second set of monitoredbehaviors associated with the second UID based on a Map Reduceprocessing operation; and in the event that the first set of monitoredbehaviors is related to the second set of monitored behaviors, join thefirst UID and the second UID; B) determine whether a first loginassociated with the first UID matches a second login associated with thesecond UID; and in the event that the first login matches the secondlogin, join the first UID and the second UID; C) determine whether afirst unique information associated with the first UID matches a secondunique information associated with the second UID; and in the event thatthe first unique information matches the second unique information, jointhe first UID and the second UID; or D) determine whether a first emailincluding a first unique identifier or code associated with the firstUID matches a second email including a second unique identifier or codeassociated with the second UID; and in the event that the first uniqueidentifier or code matches the second unique identifier or code, jointhe first UID and the second UID; and a memory coupled to the processorand configured to provide the processor with instructions.
 3. The systemrecited in claim 2, wherein the first UID is associated with a firstuser platform, and the second UID is associated with a second userplatform.
 4. The system recited in claim 2, wherein the first UID isassociated with a first mobile device, and the second UID is associatedwith a second mobile device, and wherein at least one of the first UIDand the second UID corresponds to an anonymous UID.
 5. The systemrecited in claim 2, wherein the one or more monitored behaviors aretracked using a pixel log.
 6. The system recited in claim 2, wherein theone or more IPs are tracked using a pixel log.
 7. The system recited inclaim 2, wherein the processor is further configured to: determine anumber of UIDs associated with each of the one or more IPs to categorizeeach of the one or more IPs.
 8. The system recited in claim 2, whereinthe processor is further configured to: generate a joined user profilebased on the first UID and the second UID.
 9. The system recited inclaim 2, wherein the processor is further configured to: generate ajoined user profile based on the first UID and the second UID; and sendthe joined user profile to a web service.
 10. The system recited inclaim 2, wherein the processor is further configured to: generate ajoined user profile based on the first UID and the second UID; and sendthe joined user profile to a web service, wherein the web service cancustomize content presented by the web service to a user based on thejoined user profile.
 11. A method of cross platform user joining,comprising: associating a first user identification (UID) and a secondUID with one or more Internet Protocol addresses (IPs); associating thefirst UID and the second UID with one or more monitored behaviors; andjoining the first UID and the second UID based on the one or more IPsand the one or more monitored behaviors, wherein the joining of thefirst UID and the second UID includes one of the following: A) determinewhether a first set of monitored behaviors associated with the first UIDis related to a second set of monitored behaviors associated with thesecond UID based on a Map Reduce processing operation; and in the eventthat the first set of monitored behaviors is related to the second setof monitored behaviors, join the first UID and the second UID; B)determine whether a first login associated with the first UID matches asecond login associated with the second UID; and in the event that thefirst login matches the second login, join the first UID and the secondUID; C) determine whether a first unique information associated with thefirst UID matches a second unique information associated with the secondUID; and in the event that the first unique information matches thesecond unique information, join the first UID and the second UID; or D)determine whether a first email including a first unique identifier orcode associated with the first UID matches a second email including asecond unique identifier or code associated with the second UID; and inthe event that the first unique identifier or code matches the secondunique identifier or code, join the first UID and the second UID. 12.The method of claim 11, wherein the first UID is associated with a firstuser platform, and the second UID is associated with a second userplatform.
 13. The method of claim 11, wherein the first UID isassociated with a first mobile device, and the second UID is associatedwith a second mobile device, and wherein at least one of the first UIDand the second UID corresponds to an anonymous UID.
 14. The method ofclaim 11, further comprising: determining a number of UIDs associatedwith each of the one or more IPs to categorize each of the one or moreIPs.
 15. The method of claim 11, further comprising: generating a joineduser profile based on the first UID and the second UID; and sending thejoined user profile to a web service, wherein the web service cancustomize content presented by the web service to a user based on thejoined user profile.
 16. A computer program product for cross platformuser joining, the computer program product being embodied in a tangiblecomputer readable storage medium and comprising computer instructionsfor: associating a first user identification (UID) and a second UID withone or more Internet Protocol addresses (IPs); associating the first andsecond UIDs with one or more monitored behaviors; and joining the firstand second UIDs based on the one or more IPs and the one or moremonitored behaviors, wherein the joining of the first UID and the secondUID includes one of the following: A) determining whether a first set ofmonitored behaviors associated with the first UID is related to a secondset of monitored behaviors associated with the second UID based on a MapReduce processing operation; and in the event that the first set ofmonitored behaviors is related to the second set of monitored behaviors,joining the first UID and the second UID; B) determining whether a firstlogin associated with the first UID matches a second login associatedwith the second UID; and in the event that the first login matches thesecond login, joining the first UID and the second UID; C) determiningwhether a first unique information associated with the first UID matchesa second unique information associated with the second UID; and in theevent that the first unique information matches the second uniqueinformation, joining the first UID and the second UID; or D) determiningwhether a first email including a first unique identifier or codeassociated with the first UID matches a second email including a secondunique identifier or code associated with the second UID; and in theevent that the first unique identifier or code matches the second uniqueidentifier or code, joining the first UID and the second UID.
 17. Thecomputer program product recited in claim 16, wherein the first UID isassociated with a first user platform, and the second UID is associatedwith a second user platform.
 18. The computer program product recited inclaim 16, wherein the first UID is associated with a first mobiledevice, and the second UID is associated with a second mobile device,and wherein at least one of the first UID and the second UID correspondsto an anonymous UID.
 19. The computer program product recited in claim16, further comprising computer instructions for: determining a numberof UIDs associated with each of the one or more IPs to categorize eachof the one or more IPs.
 20. The computer program product recited inclaim 16, further comprising computer instructions for: generating ajoined user profile based on the first UID and the second UID; andsending the joined user profile to a web service, wherein the webservice can customize content presented by the web service to a userbased on the joined user profile.